The following meanings for the abbreviations used in this specification apply:    ARP Allocation/Retention Priority    CmCH-PI Common Transport Channel Priority Indicator    CN Core Network    DPI Deep Packet Inspection    DSCP Differentiated Services Code Point    DT Discard Timer    FC Flow Control    FP Frame Protocol    GBR Guaranteed Bit Rate    GGSN Gateway GPRS Support Node    GPRS General Packet Radio Service    GTP GPRS Tunneling Protocol    HSPA High-Speed Packet Access    HSDPA High-Speed Downlink Packet Access    HS-DSCH High Speed Downlink Shared Channel    ID Identity    IP Internet Protocol    MAC Medium Access Control    PDU Protocol Data Unit    PF-RAD-DS Proportional Fair with Required Activity Detection, Delay Sensitive    QoS Quality of Service    RNC Radio Network Controller    SPI Scheduling Priority Indicator    TCP Transmission Control Protocol    THP Traffic Handling Priority    TS Timestamp    UE User Equipment    WFQ Weighted Fair Queuing
Some embodiments of the present invention relate to HSPA systems, although not limited thereon. In HSPA systems, user traffic is delivered through data bearers (bearer services). Core Network (CN) bearers create the logical connectivity between the CN and the Radio Network Controller (RNC), whereas Radio Access Bearers (RAB) are connecting the RNC to the User Equipments (UE). A one-to-one mapping between RABs and CN bearers is done at the RNC, thus realizing an end-to-end Universal Mobile Telecommunications System (UMTS) bearer service. Upon set-up, each bearer is mapped to a Quality of Service (QoS) class, characterized by a well defined parameter set. At bearer setup, the UE can request certain QoS parameters such as guaranteed bit rate (GBR) or traffic class (TC).
Based on that and operator policy settings, the Gateway GPRS Support Node (GGSN) determines additional parameters such as traffic handling priority (THP) and allocation/retention priority (ARP) and signals them to the RNC. The RAB specific QoS parameters, such as scheduling priority indicator (SPI) and discard timer (DT) are set by the RNC based on a mapping provided by the network operator or equipment vendor and signaled to the Node B along with the GBR. The SPI (an integer taking values from the range 0-15) specifies the priority of the data flow served by the bearer and identifies the QoS class the bearer is mapped to. DT gives the maximum allowed waiting time of the flow's packets (before being discarded) at the Node B buffers. The GBR parameter defines the target average bit rate that the air interface packet scheduler at the Node B should try to guarantee to the bearer.
These parameters are used by the Node B packet scheduler upon scheduling decisions and by the HSDPA congestion control mechanism at credit allocation. Once the active bearers receive their GBR, the packet scheduler is supposed to distribute the remaining air interface resources by considering the priority of the bearers. The packet scheduler implemented in the NSN Node Bs use the PF-RAD-DS discipline, which is able to provide the GBR (given that the channel quality of the UE allows it) and to differentiate among the bearers based on an additional parameter, the scheduling weight (wSPI), which is pre-configured in the Node B for each SPI (i.e., not signaled from the RNC). For each bearer, the packet scheduler maintains a mapping of the bearer identity to the SPI of the bearer, which in turn determines the wSPI to be used for that bearer.
Currently, due to network and equipment limitations, the entire data traffic of the users generated by the various applications is served by one data bearer. Since the QoS architecture is bearer centric (each bearer is mapped to one of the 16 QoS classes identified by the SPI), all applications of the user receive the same service, i.e., according to the parameters signaled during the bearer set-up regardless of their different quality requirements; therefore, application specific traffic discrimination is problematic. It is difficult for operators to enforce policies such as separately demoting bulk traffic or promoting premium services or applications. A potential solution is to use application aware mechanisms that are able to provide differentiation among the simultaneous applications run by the users.
A possible application aware mechanism applicable to downlink traffic in HSPA has the scope of dynamically promoting or demoting the data bearer by changing its SPI. As the decision to promote or demote is taken in order to positively or negatively discriminate the applications run by the user, this feature requires an application detection facility in the core network, suitably in the GGSN as this is the node capable of intercepting packets arriving from external networks such as the Internet and investigate their application level content. One possible realization of application detection is Deep Packet Inspection (DPI), which can examine the TCP/IP headers of the user traffic and (or) apply pattern detection to recognize different applications. The result of the detection needs to be conveyed to the radio node where the RAB is originated, i.e., to the RNC, which is able to modify the SPI of the RAB.
The RNC is the best choice also as it is the next entity after the GGSN in downlink that is capable of accessing the application level data is the UE itself. Propagation of the application information from the GGSN can be implemented by mapping the detected applications to priorities and marking the downlink (DL) packets accordingly, e.g., by utilizing the 6-bit Differentiated Services Code Point (DSCP) field of the inner IP header. The marking is thus encapsulated by the GPRS Tunneling Protocol (GTP) and remains hidden from the transport mechanisms on the Gn and Iu-PS interfaces. For priority mapping, the following three levels may be used: middle priority for default traffic, i.e., traffic corresponding to the original QoS settings of the bearer; high priority for traffic to be prioritized; and low priority for traffic to be deprioritized. Generalization to additional priority levels is also possible. The RNC continuously monitors the marking of the packets within a bearer and decides if the SPI of the bearer is to be changed or kept as it is. The logic specifying how to monitor the packets and how to decide about the SPI will be referred to as the SPI change algorithm.
The SPI value is encoded by the RNC into the HS-DSCH FP header (CmCH-PI field) that carries the traffic of the bearer from the RNC to the Node B. When processing the FP layer frames, the Node B inspects the actual SPI value encoded in the FP header. In case the SPI signaled by the RNC differs from the current SPI of the bearer, an SPI change request is generated and the related bearer parameters (SPI and wSPI) are updated according to the received SPI as soon as possible, i.e., the processing load of the Node B allows it. This is illustrated in FIG. 3.
Due to the hardware/system limitations, the Node B may be capable of processing only a limited number of SPI changes in a given time interval (e.g., 500 changes per second). If changes are requested more frequently than the rate at which they can be processed (e.g., if the activity of the users is intense that results in a significant number of SPI changes), some of the SPI change requests might not be handled at the right time or at all by the Node B, causing latency in the execution of the bearer promotion/demotion commands and eventually quality and user experience degradation.
Therefore, an intelligent management mechanism is required that is able to cope with the resource limitations while still being able to enforce the decisions of the SPI change algorithm as closely as possible.